In diesem Fall beginnen wir die Erkundung nicht mit einem ARP- oder Nmap-Scan, sondern direkt mit `enum4linux`, einem Tool zur Enumeration von Informationen aus Windows- und Samba-Systemen. Es kann aber auch Benutzerinformationen über RPC finden.
*(Hinweis: Es wird angenommen, dass die Ziel-IP 192.168.2.125 zuvor durch einen anderen Scan (z.B. arp-scan) ermittelt wurde, auch wenn dies im Log nicht direkt vor enum4linux steht.)*
========================== | Users on 192.168.2.125 | ========================== index: 0x1 RID: 0x3e8 (1000) Name: dad Desc: (null) Relative ID: 1000 index: 0x2 RID: 0x3e9 (1001) Name: mum Desc: (null) Relative ID: 1001 index: 0x3 RID: 0x3ea (1002) Name: baby Desc: (null) Relative ID: 1002 [...] [+] Enumerating users using SID S-1-22-1 and logon username '', password '' S-1-22-1-1000 Unix User\dad (Local User) S-1-22-1-1001 Unix User\mum (Local User) S-1-22-1-1002 Unix User\baby (Local User) enum4linux complete on Sat Nov 4 15:02:51 2023
**Analyse:** `enum4linux -a` führt eine umfassende Enumeration auf dem Ziel `192.168.2.125` durch. Das Tool identifiziert erfolgreich drei lokale Unix-Benutzer über deren SIDs (Security Identifiers): `dad` (UID 1000), `mum` (UID 1001) und `baby` (UID 1002).
**Bewertung:** Wichtige Information gewonnen. Wir kennen nun die Namen der Benutzer auf dem System. Dies ist nützlich für spätere Login-Versuche oder um Berechtigungen zuzuordnen.
**Empfehlung (Pentester):** Die gefundenen Benutzernamen für Brute-Force-Angriffe (z.B. gegen SSH) oder als Ziele für Privilege Escalation verwenden. Versuchen, ob für diese Benutzer Standard- oder schwache Passwörter existieren. **Empfehlung (Admin):** RPC-basierte Benutzerenumeration einschränken, wenn möglich. Starke Passwörter für alle Benutzer erzwingen.
Nachdem wir die Benutzernamen kennen, versuchen wir, uns per SSH anzumelden. Der Bericht impliziert, dass ein SSH-Schlüssel für den Benutzer 'baby' erlangt wurde (der Schritt, wie der Schlüssel erlangt wurde, fehlt im Log).
Linux family2 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 [...] Last login: [...] baby@family2:~$ # Login erfolgreich!
**Analyse:** Wir setzen die korrekten Berechtigungen für einen vorhandenen privaten SSH-Schlüssel (`id_rsa`). Anschließend verwenden wir diesen Schlüssel (`-i id_rsa`), um uns als Benutzer `baby` auf dem Zielsystem (`192.168.2.125`) per SSH anzumelden. Der Login ist erfolgreich.
**Bewertung:** Initialer Zugriff erfolgreich erlangt! Wir haben eine Shell als Benutzer `baby`. Der Weg zur Beschaffung des SSH-Schlüssels bleibt unklar, aber der Zugriff ist gegeben.
**Empfehlung (Pentester):** Umgebung als `baby` erkunden. `sudo -l` prüfen, Home-Verzeichnis untersuchen, nach weiteren Hinweisen oder Schwachstellen suchen. **Empfehlung (Admin):** SSH-Schlüssel sicher verwalten. Unnötige Schlüssel entfernen. SSH-Zugriff auf notwendige Benutzer beschränken.
Als Benutzer `baby` suchen wir nach Wegen zur Rechteerweiterung. Wir prüfen zuerst die `sudo`-Berechtigungen.
Matching Defaults entries for baby on family2:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User baby may run the following commands on family2:
(mum) NOPASSWD: /usr/bin/soelim
root:x:0:0:root:/root:/bin/bash dad:x:1000:1000:,,,:/home/dad:/bin/bash mum:x:1001:1001:,,,:/home/mum:/bin/bash baby:x:1002:1002:,,,:/home/baby:/bin/bash
**Analyse:** * `sudo -l` zeigt, dass der Benutzer `baby` den Befehl `/usr/bin/soelim` als Benutzer `mum` ohne Passwort (`NOPASSWD`) ausführen darf. `soelim` ist ein Tool, das normalerweise `.so`-Direktiven in Groff-Dateien interpretiert (oft zum Einbinden anderer Dateien verwendet). * Die Überprüfung der `/etc/passwd` bestätigt die Existenz der Benutzer `dad`, `mum` und `baby` mit Bash-Shells.
**Bewertung:** Dies ist ein klarer Vektor zur Privilege Escalation von `baby` zu `mum`. Da `soelim` Dateien einbinden kann, können wir versuchen, es zu missbrauchen, um Dateien zu lesen, auf die nur `mum` Zugriff hat, insbesondere ihren privaten SSH-Schlüssel.
**Empfehlung (Pentester):** `sudo -u mum soelim [Dateipfad]` verwenden, um zu versuchen, Dateien als `mum` zu lesen. Ziel ist `/home/mum/.ssh/id_rsa`. GTFOBins nach `soelim` durchsuchen. **Empfehlung (Admin):** Unsichere `sudo`-Regeln vermeiden. Tools wie `soelim`, die Dateiinhalte lesen können, sollten nicht über `sudo` für andere Benutzer zugänglich gemacht werden, es sei denn, es ist absolut notwendig und sicher implementiert.
.lf 1 /home/mum/.ssh/id_rsa -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn NhAAAAAwEAAQAAAYEAo8d07Ufqv8Iu7FoRUcYz8WROGwykIW72J1geSGt4qHWmsnheUleB [...] (Inhalt des privaten Schlüssels von mum) [...] 12woT6vwxJminG0qhVpq/4xAAAACm11bUBkZWJpYW4= -----END OPENSSH PRIVATE KEY-----
soelim: can't open '/home/dad/.ssh/id_rsa': Permission denied
**Analyse:** 1. Wir führen `sudo -u mum soelim /home/mum/.ssh/id_rsa` aus. Da der Befehl als `mum` ausgeführt wird, hat `soelim` Leserechte auf den privaten Schlüssel von `mum`. Der Inhalt des Schlüssels wird auf die Standardausgabe geschrieben. 2. Ein Test, ob wir auch den Schlüssel von `dad` lesen können (`sudo -u mum soelim /home/dad/.ssh/id_rsa`), schlägt fehl (`Permission denied`), da `mum` keine Leserechte auf das Home-Verzeichnis von `dad` hat.
**Bewertung:** Erfolg! Wir haben den privaten SSH-Schlüssel des Benutzers `mum` extrahiert, indem wir die `sudo`-Berechtigung für `soelim` ausgenutzt haben.
**Empfehlung (Pentester):** Den privaten SSH-Schlüssel von `mum` kopieren, in einer Datei speichern (z.B. `rsamam`), die Berechtigungen korrekt setzen (`chmod 600`) und sich damit als `mum` per SSH anmelden (wahrscheinlich auf `localhost`, da wir schon auf der Maschine sind). **Empfehlung (Admin):** Unsichere `sudo`-Regel für `soelim` entfernen.
Wir haben den SSH-Schlüssel von `mum` extrahiert und melden uns nun als `mum` an, um weiter nach Privesc-Möglichkeiten zu suchen.
Linux family2 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 [...] You have new mail. Last login: Mon Nov 1 13:33:56 2021 from 192.168.0.43 mum@family2:~$ # Login als mum erfolgreich!
Matching Defaults entries for mum on family2:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User mum may run the following commands on family2:
(root) NOPASSWD: /usr/bin/shred -f -z /etc/passwd
(dad) ALL
**Analyse:** 1. Wir melden uns erfolgreich als `mum` per SSH mit dem extrahierten Schlüssel an. 2. Wir führen `sudo -l` für `mum` aus und finden zwei interessante Einträge: * Sie darf `/usr/bin/shred -f -z /etc/passwd` als `root` ohne Passwort ausführen. Dies würde die `/etc/passwd`-Datei zerstören, was destruktiv und wahrscheinlich nicht direkt für Privesc nützlich ist, aber eine interessante Fehlkonfiguration darstellt. * Sie darf **jeden** Befehl (`ALL`) als Benutzer `dad` ausführen. Dies erfordert jedoch wahrscheinlich das Passwort von `mum`.
**Bewertung:** Die `shred`-Berechtigung ist seltsam, aber der entscheidende Fund ist `(dad) ALL`. Wenn wir das Passwort von `mum` herausfinden, können wir direkt zu `dad` wechseln.
**Empfehlung (Pentester):** Die Umgebung von `mum` untersuchen, insbesondere Umgebungsvariablen (`printenv`, `env`), Bash-History, Notizen etc., um ihr Passwort zu finden. Falls gefunden, `sudo -u dad bash` ausführen. **Empfehlung (Admin):** Destruktive Befehle wie `shred` niemals über `sudo` erlauben. `(user) ALL`-Berechtigungen sind sehr mächtig und sollten nur mit Bedacht und Passwortschutz vergeben werden.
SHELL=/bin/bash
PWD=/home/mum
LOGNAME=mum
XDG_SESSION_TYPE=tty
passwd=LA0172 <<---- mums password
MOTD_SHOWN=pam
HOME=/home/mum
LANG=en_US.UTF-8
[...]
[sudo] password for mum: LA0172 dad@family2:/home/mum$ # Shell als dad erhalten!
**Analyse:** 1. Der Befehl `printenv` listet die Umgebungsvariablen für `mum` auf. Überraschenderweise finden wir eine Variable namens `passwd` mit dem Wert `LA0172`. Dies ist höchstwahrscheinlich das Passwort von `mum`. 2. Wir führen `sudo -u dad bash` aus. Das System fragt nach dem Passwort von `mum`. Wir geben das gefundene Passwort `LA0172` ein. 3. Der Befehl ist erfolgreich, und wir erhalten eine Shell als Benutzer `dad`.
**Bewertung:** Privilege Escalation von `mum` zu `dad` erfolgreich! Das Passwort wurde durch eine unsichere Umgebungsvariable preisgegeben.
**Empfehlung (Pentester):** Umgebung als `dad` untersuchen. User-Flag lesen. Nach Wegen zu Root suchen (SUID-Dateien, Cronjobs etc.). **Empfehlung (Admin):** Niemals Passwörter in Umgebungsvariablen speichern! Dies ist eine extrem unsichere Praxis.
Wir haben eine Shell als `dad` und suchen den letzten Schritt zur Root-Eskalation.
141691 472 -rwsr-xr-x 1 root root 481608 Mar 13 2021 /usr/lib/openssh/ssh-keysign
138035 52 -rwsr-xr-- 1 root messagebus 51336 Feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
130919 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh
152482 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/bin/sudo
134953 56 -rwsr-xr-x 1 root root 55528 Jul 28 2021 /usr/bin/mount
134955 36 -rwsr-xr-x 1 root root 35040 Jul 28 2021 /usr/bin/umount
130918 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn
134495 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp
130921 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd
130922 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd
134639 72 -rwsr-xr-x 1 root root 71912 Jul 28 2021 /usr/bin/su
57 16 -rwsr-sr-x 1 root root 16096 Oct 31 2021 /opt/clock
**Analyse:** Wir suchen als `dad` nach SUID-Binaries (`-perm -4000`). Neben den üblichen Standard-Binaries finden wir ein benutzerdefiniertes SUID-Binary: `/opt/clock`. Es gehört `root` und hat das SUID-Bit gesetzt (`-rwsr-sr-x`), was bedeutet, dass es immer mit Root-Rechten ausgeführt wird.
**Bewertung:** Dies ist ein sehr vielversprechender Fund. Ein benutzerdefiniertes SUID-Binary ist oft ein absichtlich oder unabsichtlich platzierter Weg zur Rechteerweiterung.
**Empfehlung (Pentester):** Das Binary `/opt/clock` untersuchen. Mit `strings /opt/clock` nach interessanten Zeichenketten suchen. Mit `ltrace /opt/clock` oder `strace /opt/clock` das Verhalten analysieren. Versuchen, es auszuführen und zu sehen, was es tut. Prüfen, ob es externe Befehle mit relativen Pfaden aufruft, was eine PATH-Manipulation ermöglichen würde. **Empfehlung (Admin):** Benutzerdefinierte SUID-Binaries vermeiden oder extrem sorgfältig prüfen und härten. Nur absolut notwendige SUID-Bits setzen.
Wir untersuchen das `/opt/clock`-Binary (impliziert) und stellen fest, dass es wahrscheinlich den `date`-Befehl ohne absoluten Pfad aufruft. Wir nutzen dies durch PATH-Hijacking aus.
**Analyse:** 1. Wir wechseln nach `/tmp` (ein beschreibbares Verzeichnis). 2. Wir erstellen eine Datei namens `date` und schreiben den String `/bin/bash` hinein. 3. Wir machen diese Datei ausführbar (`chmod +x`). 4. Wir manipulieren die `PATH`-Umgebungsvariable, indem wir `/tmp` an den Anfang stellen (`export PATH=/tmp:$PATH`). Das bedeutet, wenn ein Programm einen Befehl ohne absoluten Pfad aufruft (z.B. nur `date`), sucht das System zuerst in `/tmp`, bevor es die Standardpfade wie `/bin` oder `/usr/bin` durchsucht. 5. Wir führen das SUID-Binary `/opt/clock` aus. Wir nehmen an, dass `/opt/clock` intern versucht, den Befehl `date` aufzurufen, um die Zeit anzuzeigen. Wegen unserer PATH-Manipulation findet es nun zuerst unsere präparierte `date`-Datei in `/tmp` und führt diese aus. Der Inhalt unserer Datei ist `/bin/bash`. 6. Da `/opt/clock` als Root läuft (wegen SUID), wird auch unser `/bin/bash`-Befehl als Root ausgeführt. Wir erhalten eine Root-Shell.
**Bewertung:** Privilege Escalation zu Root erfolgreich! Die Schwachstelle lag darin, dass das SUID-Binary `/opt/clock` einen externen Befehl (`date`) ohne absoluten Pfad aufrief, was PATH-Hijacking ermöglichte.
**Empfehlung (Pentester):** Flags lesen. Bericht abschließen. **Empfehlung (Admin):** **SUID-Binary `/opt/clock` korrigieren oder entfernen!** In SUID-Binaries immer absolute Pfade für externe Befehle verwenden (z.B. `/bin/date` statt `date`). Die `PATH`-Variable in SUID-Programmen vor der Verwendung externer Befehle zurücksetzen oder validieren.
Als Root lesen wir die Flags.
7177e6f98837966e1ce5d93c59ba0453
user.txt
802809d489f8684f00fd6b8970724283
user.txt
802809d489f8684f00fd6b8970724283
root.txt
7177e6f98837966e1ce5d93c59ba0453
**Analyse:** Aus der Root-Shell lesen wir die `root.txt` aus `/root/` und die `user.txt` aus `/home/dad/`.
**Bewertung:** Beide Flags erfolgreich gelesen.
**Empfehlung (Pentester):** Ergebnisse dokumentieren. **Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.